1. Field of the Invention
This invention relates generally to validating documents, and more particularly to methods and apparatus for validating electronic documents used in mortgage transactions.
2. Description of the Related Art
Information is being increasingly processed electronically in lieu of traditional paper processes. Electronic documents offer substantial benefits, such as cost reduction and the accommodation of rapid manipulation and organization of information. Over the years, laws and business customs have evolved to address concerns associated with paper documents including authenticity (that a document is what it purports to be and has been actually signed by the appropriate entities), integrity (that a document is complete and unaltered), and validity (that a document complies with business and legal rules). Validation of electronic documents should address and satisfy these concerns to support the adoption of electronic documents in various environments.
Although conventional electronic documents address some of the traditional paper document concerns, they remain problematic in several respects. One problem with electronic documents is that, although they are capable of being rapidly processed, they must still integrate with environments in which their content will need to be accurately and verifiably displayed (e.g., printed, rendered on a monitor, etc.). This is particularly true for mortgage transactions, where documents such as promissory notes are still routinely used in paper form during certain procedures, such as closings. Although the data contained on a printed document could be transferred to an electronic document, in many applications such an electronic document could not be properly validated due to the lack of adequate assurances that the data contained in the electronic document actually corresponds to the printed (or otherwise viewed) document used in an underlying transaction. The printed document could be manually compared to the data in the electronic document in order to validate the electronic document, but such a practice would negate many of the benefits of electronic processing. Alternatively, a conventional markup language could be used to define an electronic document having displayable information. However, in such a case the listing for rendering a display would contain a substantial amount of information not required for subsequent data processing. Moreover, the format of the listing might not be amenable to rapid and accurate processing in many circumstances, and might not be formatted for related transactions.
Another problem with electronic document validation is the potential for document variation within an industry, as dictated by individual practices, or by the various conditions in which an electronic document might be processed. For example, in mortgage transactions, certain lenders may have a common set of requirements for document validity, but might supplement these with their own particular requirements. A conventional electronic document (e.g., an XML document) can have a specification, such as a document type definition (DTD) that identifies constraints used to determine whether the document is valid, such as whether it contains tags that are not permitted by the DTD. However, while checking for a set of known elements is known, such validation would be inadequate where divergent document requirements are encountered. Specifically, a document may be valid according to a DTD, but invalid according to the format and content required by a particular lender.
Furthermore, although conventional electronic document definitions include some general mechanisms for validating document integrity with regard to associating values to attributes (e.g. XML validation can ensure that an IDREF points to an ID that is actually defined in a document), there are not adequate assurances that actual values are appropriate for particular applications. That is, conventional validation applies a mechanical determination as to the existence of pairing, but provides no assurance that particular field and value pairings are appropriate for a given environment, and does not necessarily detect a faulty pairing.
Still further, related transactions might use separate documents that contain some common information, but which are not necessarily identical. For example, in the real estate environment, a closing will require certain documents, but related post-closing activities might require other documents. Conventional electronic document validation does not adequately address such scenarios.
Thus, what is needed is electronic document validation that verifies the correspondence of processed data to that contained on documents actually used in transactions, that is flexible in handling potentially divergent document and data requirements, and that provides greater assurances of data integrity than is provided with conventional electronic document validation.